1. Technical Field
The present invention relates to the network management of services or features in telephone networks and, more specifically, to the network management of the calling name (CNAM) service in telephone networks which also provide a number portability (NP) service.
2. Related Prior Art
Historically, telephone companies introduced new calling services or features for their customers through new releases of the software used in their switches. This, however, resulted in a slow introduction of new services and the restriction of those services to whatever new features were included in the latest software release from the switch vendors. In response to these problems, the telephone industry developed a new network design, known as the Intelligent Network (IN), which distributes at least some of the intelligence (software) underlying the provision of calling services out of the switch and into peripheral call processing computers. The local switch can access these computers during call processing so as to deliver the desired services.
In early implementations of the IN architecture, the switch maintained control over the call processing and merely requested and received data from the peripheral devices. In current implementations of the IN architecture, however, at least some of the intelligence to process calls may be offloaded from the switch to a service control point (SCP) whose software can be readily modified by the local carrier in order to provide new calling services (e.g., voicemail). The SCP may delegate some of the tasks of call processing to one or more intelligent peripherals (IPs) which operate as slave processors to the SCP and can provide a variety of resources (e.g., voice recognition).
The current IN architecture may further include a service node (SN), which comprises a standalone computer platform dedicated to providing a particular calling service autonomously (i.e., independently of the SCP or the switch). The various IN elements or nodes (i.e., switches, SCPs, IPs and SNs) are interconnected by a common channel signaling (CCS) data network which uses, for example, the Signaling System No. 7 (SS7) protocol. The SS7 network typically includes a signaling transfer point (STP) for routing the messages (data packages) among the various IN elements.
In the IN architecture, during call processing the switch analyses call related information (e.g., calling customer service profile record, dialed digits, etc.) to determine whether it requires an IN feature for routing the call or providing a calling service. If the switch detects that an IN feature should be invoked, it sends a query (data message) to the SCP over the SS7 network. In response, the SCP can assume control over call processing and execute the desired service internally or, as necessary, invoke an external resource (IP, SN or another SCP) which can deliver the desired service. Alternatively, the SCP may simply access a database and return the desired data (e.g., routing information) to the switch over the SS7 network.
Among the IN features currently under development is the number portability (NP) feature. The NP feature gives a telephone subscriber the ability to change his or her local service without having to change his or her existing telephone directory number (DN), which in the United States usually is a 10-digit number represented by NPA-NXX-XXXX (where "NPA" designates the numbering plan area in which the subscriber is located, "NXX" is a 3-digit prefix assigned to the local switch to which the subscriber is connected, and "XXXX" is a four-digit suffix assigned by the local switch operator to the subscriber). Thus, a subscriber to the NP feature may change his or her telephone service, for example, from plain old telephone service (POTS) to an integrated services digital network (ISDN), from one telephone service provider to another, or from one physical location to another, while retaining the same DN. The first phase for NP implementation, called local number portability (LNP), covers changing service providers or physical locations within a rate center while using a "portable" DN assigned by one of the networks in that rate center (i.e., a DN from a NPA-NXX number series belonging to that network and designated by that network for use as a portable number series). Such subscription changes are recorded in a LNP database maintained by the SCP of that network.
Two functions are slated to be added to the network in order to support the LNP feature, namely, the location routing number (LRN) function and the global title translation (GTT) relay function. The LRN function allows the switch that is processing a call to a portable DN to send a query containing that DN to the SCP requesting routing information for the switch to which the called DN is now connected. The SCP checks its LNP database and returns to the inquiring switch a response message containing the LRN for the switch that currently serves the called subscriber so that the call can be routed to the serving switch. The GTT relay function, on the other hand, allows the network to route queries relating to a portable DN to the appropriate destination(s). Prior to deployment of the LNP feature, the first six digits of any DN (i.e., the NPA-NXX) could be used for identifying the switch (and network) to which the corresponding subscriber is connected. However, the first six digits of a portable DN cannot be used for this identification purpose (since the subscriber now has changed location or telephone companies). The GTT relay function thus is used to determine the address for the network node(s) that provide(s) the desired service or feature for a portable subscriber (e.g., a destination point code for a particular node or a capability code specifying a group of nodes capable of performing a particular function). The GTT relay function can be implemented in a network node such as a STP, for example. Queries relating to a portable DN can be directed to the GTT relay node which translates the portable DN in the query into the correct destination address.
Another current network feature is the calling name (CNAM) delivery service, also known as the caller ID with name feature. The CNAM feature allows the customer premises equipment (CPE) of the called party to record and display the name of the calling party and the date and time of the call during the first silent interval in the ringing cycle. To effect CNAM delivery the SCP is provided with a database containing a list of DNs and corresponding subscriber names. During call processing the switch can send a message containing the calling party number to the SCP which then performs a lookup in the CNAM database to find the subscriber name associated with the calling party number. Once found in the CNAM database, the name of the calling party can be returned in a response message from the SCP to the switch which, in turn, forwards that name to the CPE of the called party.
Since the CNAM database may be shared among several switches in the network, it is possible that the SCP containing the CNAM database may become overloaded with queries for the CNAM database. The SCP therefore is provided with an automatic call/code gapping (ACG) load control function which enables the SCP to order a particular node (e.g., switch) for a particular period of time to send no more than one CNAM query for any number belonging to a particular NPA-NXX series per a certain gap interval. The duration of the overload protection period and the length of the gap interval are specified in the order from the SCP to the node. After ACG is invoked in a node against a particular NPA-NXX number series and for the duration of the overload protection period, whenever that node sends to the SCP a CNAM query for a number in that NPA-NXX series, no other CNAM query for that NPA-NXX series can be sent from that node for a time period equal to the defined gap interval. This reduces the frequency of CNAM queries by that node for that NPA-NXX series to no more than one query per gap interval.
While the ACG network management function may be considered necessary for effective deployment of the CNAM feature, application of the ACG function may lead to undesirable results in interconnected networks which support both the LNP and CNAM features, such as the three exemplary networks shown in FIG. 1. Referring to FIG. 1, for the sake of simplicity, it is assumed that in each of the three networks the LNP and CNAM features are provided by a single SCP. Thus, the first network includes a SCP 16 having a LNP database (LNP DB) 18 and a CNAM database (CNAM DB) 20, while the second network includes a SCP 36 having a LNP DB 38 and a CNAM DB 40, and the third network includes a SCP 56 having a LNP DB 58 and a CNAM DB 60. The GTT relay function is assumed to have been implemented in STPs 14, 34 and 54 in the first, second and third networks, respectively.
Assume that a subscriber 10 in the first network places a call to a subscriber 30 in the second network. Assume further that the subscriber 10 has ported his telephone number from the second network (i.e., this telephone number belongs to a portable NPA-NXX series assigned by the second network) and that the subscriber 30 has the CNAM feature activated. The call from the subscriber 10 is handled by the local switch in the end office (EO) 12 in the first network. The EO 12 analyses the dialed digits and sends call setup signaling data via STPs 14 and 34 to EO 32 in the second network where the called subscriber 30 is located. The EO 32 checks the subscriber profile for the subscriber 30 and determines that the CNAM feature is activated for this subscriber. Consequently, the EO 32 generates a CNAM query containing the calling party number (CgPN) and routes this CNAM query to the local SCP 36. Upon receiving the CNAM query, the SCP 36 will not be able to find the CgPN in the CNAM DB 40 (since the number has been ported). Thus, the SCP 36 will formulate a so-called CNAM "requery" for transmission to the STP 34 (which implements the GTT relay function necessary for routing queries for portable numbers to the appropriate destination).
With continuing reference to FIG. 1, the GTT relay function in the STP 34 in the second network will route the CNAM query received from the SCP 36 to the STP 14 which provides the GTT relay function in the first network. The STP 14 will route the CNAM query to the SCP 16 which maintains CNAM DB 20 containing the CgPN and other numbers connected to the EO 12. If the SCP 16 is in overload condition, the response message from the SCP 16 to the SCP 36 will contain an ACG order requesting SCP 36 to apply gapping (in accordance with the ACG data in the message) to subsequent CNAM requeries relating to DNs in the NPA-NXX series of the portable CgPN. However, if most of the other 9999 subscribers in this portable series reside in the third network rather than in the first network, application of gapping to this number series at the SCP 36 means that CNAM queries relating to these other subscribers (e.g., subscriber 50) are gapped by the SCP 36 even though such queries would be handled by the CNAM DB 60 at the SCP 56, which may not be under an overload condition. In other words, the CNAM overload condition in one network may result in interference with the management of CNAM operations in other networks that may not be experiencing a similar overload problem.
This interference problem also occurs if the EO 32 were to global title route the initial CNAM query instead of routing it to the SCP 36. In this case, the CNAM query would be routed from the EO 32 through the STPs 34 and 14 to the SCP 16. The CNAM response message containing the ACG order from SCP 16 would be returned to the EO 32. If most of the other 9999 subscribers in the portable NPA-NXX series of the CgPN reside in the second network or the third network, application of gapping to this series at the EO 32 means that CNAM queries relating to these other subscribers are gapped by the EO 32 even though such queries would be handled by the SCP 36 or the SCP 56, which may not be under an overload condition.